home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000125_rts _Thu May 13 21:16:28 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  3KB
  1. Received: from boojum.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA06647; Thu, 13 May 1993 21:16:29 MST
  3. Date: Thu, 13 May 1993 21:16:28 MST
  4. From: "Rick Snodgrass" <rts>
  5. Message-Id: <199305140416.AA11476@boojum.cs.arizona.edu>
  6. Received: by boojum.cs.arizona.edu; Thu, 13 May 1993 21:16:28 MST
  7. To: tsql@cs.arizona.edu
  8. Subject: Shashi's comments
  9.  
  10. Shashi makes some good points about both the taxonomy and the instance.
  11. I wish he had made these points when these were being actively designed
  12. and discussed.
  13.  
  14. As it is, it is now only four weeks from the workshop. If we start
  15. redesigning the instance and the taxonomy now, there is no way we
  16. will have a draft benchmark ready for the workshop.
  17.  
  18. Recall that this effort started several months ago. There has been
  19. a great deal of constructive technical discussion about all the
  20. portions of the benchmark, from the objectives, to the schema, to
  21. the instance, to the taxonomy. The traffic on tsql related solely
  22. to the benchmark has averaged approximately one message per day. Many
  23. people have made general and specific suggestions that have been
  24. incorporated into the present document.
  25.  
  26. Christian has tried to keep us on schedule by moving on to the next
  27. topic once a general consensus has been reached. He recommended some
  28. time ago that we consider the instance and the taxonomy finalized,
  29. and move on to the last task, that of writing the queries. There was
  30. little disagreement on this at the time.
  31.  
  32. I suggest that we stick with this schedule. After the workshop, we'll
  33. have a better understanding both of the first version of the benchmark,
  34. because it will actually exist, as well as other aspects of temporal
  35. DB infrastructure. At that point, we can revisit all portions of
  36. the benchmark. Others also have concerns that should be addressed at
  37. that time. The second version of the benchmark will be much stronger
  38. as a result.
  39.  
  40. An alternative is to simply decide that the schedule of completing an
  41. initial version of the benchmark is simply unrealistic. I am strongly
  42. opposed to that alternative, because I believe that without a schedule,
  43. we would still be discussing task 1, and a benchmark would never emerge.
  44. However, I also strongly feel that this effort needs to be by consensus,
  45. so I put the following question on the floor, for (hopefully quick)
  46. discussion and resolution:
  47.  
  48.     Should we continue to generate an initial draft of the benchmark
  49.     by June 16, or should we consider that goal unrealistic, and
  50.     resume discussion of the objectives, schema, instance, and
  51.     taxonomy before moving on to the queries at some later date?
  52.  
  53. I request that all (current and potential) authors of the benchmark
  54. respond quickly with their views on this question.
  55.  
  56. Thank you.